home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13608 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: news.sprintlink.net!datalytics!usenet
  2. From: Rob Stewart <stew@datalytics.com>
  3. Newsgroups: alt.computer.consultants,comp.edu,comp.lang.basic.misc,comp.lang.c++,comp.lang.misc,comp.lang.pascal.borland,comp.lang.pascal.delphi.misc,comp.misc,comp.os.msdos.programmer,comp.os.os2.programmer.misc,comp.programming
  4. Subject: Re: Can we do programming without seeing the end user?
  5. Date: Tue, 26 Mar 1996 10:23:54 -0500
  6. Organization: Datalytics, Inc
  7. Message-ID: <31580C0A.3728@datalytics.com>
  8. References: <BYtKnOggyTxQ071yn@oslonett.no> <4j6nth$f98@epx.cis.umn.edu>
  9. NNTP-Posting-Host: 204.62.224.71
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (WinNT; I)
  14.  
  15. Henry W Miller wrote:
  16. > 
  17. > Svein Olav Mytting (bollerud@oslonett.no) wrote:
  18. > : I know a lot of you programmers work far from the end-users. Some of you
  19. > : work even far from your employer, which in turn lives far from the
  20. > : customer.
  21. > 
  22. > : I sort of believe that sales and programming should be strictly
  23. > : separate tasks. While a salesman should see his customer in person,
  24. > : a programmer shouldn't do that.
  25. > 
  26. > Accually I think the manual for the program should be written first.  The
  27. > customer should review the manual and decide if taht is how tehy want the
  28. > program to work.  Then the programmer takes the manual and tunrs that into teh
  29. > user interface.   Most programers have no idea how to write a user interface
  30. > so tehy need a guide.  just like most construction workers work from a
  31. > bluprint programmers need something to work teh user interface on.
  32.  
  33. That's exactly right.  That's how we approach things.  It has 
  34. been great.  You see, end users are accustomed to seeing user's 
  35. manuals (though they don't always read them!).  Thus, the user's 
  36. manual is a reasonable vehicle for communicating the behavior of 
  37. the product.  If it spells out the steps to accomplish tasks and 
  38. lists screen shot mockups to illustrate features, the user can 
  39. think through the process and make specific comments.
  40.  
  41. The result is the user has a clear understand of what he wants 
  42. and the user's manual reflects that desire.  With a specific 
  43. goal in mind, the developer can now design software that does 
  44. what the user wants.  Furthermore, by requiring user investment 
  45. up front, you reduce the continuous changes encountered in 
  46. "normal" development cycles.
  47.  
  48. RAD techniques can be used to help flesh out things that are 
  49. unclear or for which the user requires hands-on testing to 
  50. decide how to do something.
  51.  
  52. Once you have a user's manual, you need to get signatures from 
  53. all important parties that it correctly and completely describes 
  54. the goal.  From that, you can write specifications and begin 
  55. design.  Don't forget to formalize the specification with 
  56. signatures.  Change control is still important.  You must make 
  57. users go through the whole process for anything except 
  58. insignificant changes.  This keeps the target from moving (at 
  59. least from moving much) while the developers are headed for it.
  60.  
  61. The result is much better software that does what the user 
  62. really wants.
  63.  
  64. -- 
  65. Robert Stewart        | My opinions are usually my own.
  66. Datalytics, Inc.    | stew@datalytics.com
  67.